PART 1

ETL

The datasets provided (issues and issuesHistory csv files) need to be cleaned and loaded into the database, so any business user can properly investigate them by simply using a SQL query or export them for a deeper analysis.

library(readr)
issues <- read.csv("~/Desktop/issues.csv")
head(issues)
##   Project      Key           Created              Status  Type
## 1     TAL TAL-1044 10/05/2018, 10:52 Waiting UX / Design Story
## 2     TAL TAL-1043 04/07/2018, 16:06               To Do Story
## 3     TAL TAL-1042 04/07/2018, 15:11         In Progress Story
## 4     TAL TAL-1041 04/07/2018, 15:09               To Do Story
## 5     TAL TAL-1040 04/07/2018, 08:00               To Do Story
## 6     TAL TAL-1039 04/07/2018, 07:52               To Do Story

Starting with the issues.csv file… Does it have any missing data?

sum(is.na(issues))
## [1] 0
length(duplicated(issues)[duplicated(issues)=="TRUE"])
## [1] 0

There are no missing values and all observations are unique. But dates in Created are not in the right format, so that needs to be amended.

issues$Created <- gsub(",","",issues$Created)
issues$Created <- as.POSIXct(issues$Created, format = "%d/%m/%Y %H:%M", tz="GMT")
issues$Key <- as.character(issues$Key)
str(issues)
## 'data.frame':    4247 obs. of  5 variables:
##  $ Project: Factor w/ 5 levels "CVAL","DFO","DW",..: 5 5 5 5 5 5 5 5 5 5 ...
##  $ Key    : chr  "TAL-1044" "TAL-1043" "TAL-1042" "TAL-1041" ...
##  $ Created: POSIXct, format: "2018-05-10 10:52:00" "2018-07-04 16:06:00" ...
##  $ Status : Factor w/ 14 levels "Blocked","Candidate - Estimate Requested",..: 14 13 6 13 13 13 13 7 5 9 ...
##  $ Type   : Factor w/ 11 levels "Bug","Bug - Sub-Task",..: 8 8 8 8 8 8 8 1 1 1 ...

In total, there were 4247 issues created between 2016-03-23 14:36:00 and 2018-07-06 11:03:00. And the issues.csv file is ready to be loaded into the DB.

write.csv(issues, "~/Desktop/READYissues.csv", row.names = FALSE, quote = FALSE)

Now let’s take a look at the issuesHistory.csv file and see what kind of cleaning it requires. As the file was being read into R, I identified a typo in row number 11918 which prevented it to proceed properly. So, I fixed it manually, saved it as issuesHistory.xlsx and used the read_xlsx function from the readxl library.

library(readxl)
history <- read_xlsx("~/Desktop/Tests/Outsystems/issuesHistory.xlsx")
history <- as.data.frame(history)

Dates in Created have the same format problem as in the issues file, so will treat them the same way.

history$Created <- gsub(",","",history$Created)
history$Created <- as.POSIXct(history$Created, format = "%d/%m/%Y %H:%M", tz="GMT")
str(history)
## 'data.frame':    18011 obs. of  10 variables:
##  $ Issue      : chr  "TAL-1044" "TAL-1044" "TAL-1044" "TAL-1042" ...
##  $ History Id : num  1220713 1220710 1220545 1218163 1218162 ...
##  $ Author     : chr  "ase" "ase" "ase" "paulo.junior" ...
##  $ Created    : POSIXct, format: "2018-07-05 12:09:00" "2018-07-05 12:09:00" ...
##  $ Field      : chr  "status" "status" "status" "status" ...
##  $ Type       : chr  "jira" "jira" "jira" "jira" ...
##  $ From       : num  10001 12400 10001 10401 14800 ...
##  $ From String: chr  "To Do" "Done" "To Do" "Ready" ...
##  $ To         : num  13900 10001 12400 11702 10401 ...
##  $ To String  : chr  "Waiting UX / Design" "To Do" "Done" "In Progress" ...

Now let’s investigate the dataset further. Does it have missing values?

sum(is.na(history))
## [1] 19
history[rowSums(is.na(history)) > 0, colSums(is.na(history)) > 0]
##       History Id             Created  Field             Type  From
## 11918    1008968 2018-01-30 16:32:00 status jirimate Request 10401
## 11919    1008967 2018-01-30 16:32:00 status             jira 10001
## 13167         NA                <NA>   <NA>             <NA>    NA
## 13993         NA                <NA>   <NA>             <NA>    NA
##       From String   To To String
## 11918       Ready   NA      <NA>
## 11919       To Do 1480      <NA>
## 13167        <NA>   NA      <NA>
## 13993        <NA>   NA      <NA>

This time we have 19 missing values across 4 observations. The first two rows belong to Issue DFO-444. Allow me to check out all its records as we might find a way to fill in those NAs.

history[history$Issue=="DFO-444",]
##         Issue History Id Author             Created  Field
## 11917 DFO-444    1019807    cia 2018-02-06 19:40:00 status
## 11918 DFO-444    1008968    epe 2018-01-30 16:32:00 status
## 11919 DFO-444    1008967    epe 2018-01-30 16:32:00 status
## 13691 DFO-444    1019807    cia 2018-02-06 19:40:00 status
## 13692 DFO-444    1008970    epe 2018-01-30 16:32:00 status
## 13693 DFO-444    1008969    epe 2018-01-30 16:32:00 status
## 13694 DFO-444    1008968    epe 2018-01-30 16:32:00 status
## 13695 DFO-444    1008967    epe 2018-01-30 16:32:00 status
##                   Type  From                                From String
## 11917             jira 14000                      Development Completed
## 11918 jirimate Request 10401                                      Ready
## 11919             jira 10001                                      To Do
## 13691             jira 14000                      Development Completed
## 13692             jira 11702                                In Progress
## 13693             jira 10401                                      Ready
## 13694             jira 14800 Kanban Candidate - Urgent Estimate Request
## 13695             jira 10001                                      To Do
##          To                                  To String
## 11917 12400                                       Done
## 11918    NA                                       <NA>
## 11919  1480                                       <NA>
## 13691 12400                                       Done
## 13692 14000                      Development Completed
## 13693 11702                                In Progress
## 13694 10401                                      Ready
## 13695 14800 Kanban Candidate - Urgent Estimate Request

By coincidence, the rows which have NAs are duplicated, as their History Id repeats. Also, the last two rows with missing values are not relevant either, so we can drop them all.

history <- na.omit(history)
sum(is.na(history))
## [1] 0
length(duplicated(history)[duplicated(history)=="TRUE"])
## [1] 1

Apparenty, still have a duplicated value. And once again, belongs to Issue DFO-444. Let’s get rid of it.

history[duplicated(history),]
##         Issue History Id Author             Created  Field Type  From
## 13691 DFO-444    1019807    cia 2018-02-06 19:40:00 status jira 14000
##                 From String    To To String
## 13691 Development Completed 12400      Done
history <- unique(history)
length(unique(history$`History Id`))
## [1] 18006

But I am not too sure about all these unique rows… There are observations where Issues’ Status don’t change, yet get a different History Id.

head(history[history$From==history$To,])
##        Issue History Id       Author             Created  Field Type  From
## 389  TAL-948    1191608 paulo.junior 2018-06-14 15:17:00 status jira 10001
## 442  TAL-938    1166546          rcp 2018-05-28 14:58:00 status jira 12400
## 596  TAL-907    1164729          ase 2018-05-26 01:02:00 status jira 10001
## 658  TAL-894    1185887          ase 2018-06-11 11:30:00 status jira 10001
## 811  TAL-869    1209543          rcp 2018-06-27 13:55:00 status jira 12400
## 1016 TAL-838    1214550 paulo.junior 2018-07-02 15:23:00 status jira 10001
##      From String    To To String
## 389        To Do 10001     To Do
## 442         Done 12400      Done
## 596        To Do 10001     To Do
## 658        To Do 10001     To Do
## 811         Done 12400      Done
## 1016       To Do 10001     To Do

It doesn’t feel right to me. So, I am going to get rid of these rows too.

history <- history[history$From!=history$To,]

In the end, we have 17879 observations for issuesHistory. Although it looks like it is ready to be loaded into the DB, I don’t find it very friendly to have different names for the same From or To IDs, as we can see below:

table(history[history$From=='10401',]$From,history[history$From=='10401',]$`From String`)
##        
##         Estimated & Ready Ready READY
##   10401                60  2177   112

For example, for Issue 10401 we see three different From Strings: Estimated & Ready, READY and Ready. Does this happen very often? Below there is a table counting the number of different names each From ID has:

aggregate(data=history, `From String`~From, function(x) length(unique(x)))
##      From From String
## 1       1           1
## 2       4           1
## 3   10001           2
## 4   10400           1
## 5   10401           3
## 6   10403           1
## 7   10700           1
## 8   11201           1
## 9   11702           2
## 10  11900           1
## 11  11901           1
## 12  12102           1
## 13  12400           1
## 14  13500           1
## 15  13700           1
## 16  13800           2
## 17  13900           2
## 18  13901           1
## 19  14000           1
## 20  14001           1
## 21  14100           1
## 22  14200           1
## 23  14800           1
## 24  14909           1
## 25 185979           1

It could be OKish to keep it like this, as a business user can always filter or select records by their From or To IDs, but I guess would be better to standardize it - I will use the most popular names. However, because they might contain relevant information (such as PO Accepted or Estimated), I will save all their former names into two new columns: From Comments and To Comments.

library(dplyr)
#Creation of comments columns
history$`From Comments` <- history$`From String`
history$`To Comments` <- history$`To String`

#Replacement of From/To Strings by their most popular names 
history <- history %>% group_by(From) %>% mutate (`From String`=names(which.max(table(`From String`)))) %>% ungroup()
history <- history %>% group_by(To) %>% mutate (`To String`=names(which.max(table(`To String`)))) %>% ungroup()

#If names are the same, there's no need to add any comment. Otherwise, let's keep this information
history$`From Comments` <- ifelse(history$`From Comments`==history$`From String`,"No Comments",history$`From Comments`)
history$`To Comments` <- ifelse(history$`To Comments`==history$`To String`,"No Comments",history$`To Comments`)

head(as.data.frame(history))
##      Issue History Id       Author             Created  Field Type  From
## 1 TAL-1044    1220713          ase 2018-07-05 12:09:00 status jira 10001
## 2 TAL-1044    1220710          ase 2018-07-05 12:09:00 status jira 12400
## 3 TAL-1044    1220545          ase 2018-07-05 12:07:00 status jira 10001
## 4 TAL-1042    1218163 paulo.junior 2018-07-04 15:34:00 status jira 10401
## 5 TAL-1042    1218162 paulo.junior 2018-07-04 15:34:00 status jira 14800
## 6 TAL-1042    1218113          ase 2018-07-04 15:11:00 status jira 10001
##                                  From String    To
## 1                                      To Do 13900
## 2                                       Done 10001
## 3                                      To Do 12400
## 4                                      Ready 11702
## 5 Kanban Candidate - Urgent Estimate Request 10401
## 6                                      To Do 14800
##                                    To String From Comments To Comments
## 1                        Waiting UX / Design   No Comments No Comments
## 2                                      To Do   No Comments No Comments
## 3                                       Done   No Comments No Comments
## 4                                In Progress   No Comments No Comments
## 5                                      Ready   No Comments No Comments
## 6 Kanban Candidate - Urgent Estimate Request   No Comments No Comments

The files are cleaned and ready to be loaded into our DB for further analysis and business use.

write.csv(history, "~/Desktop/history.csv", row.names = FALSE, quote = FALSE)

PART 2

Report

Now that we have loaded our data into our DB, we can use SQL queries to answer a few questions, such as:

  1. How many issues were created in total?

SELECT COUNT(DISTINCT key)
FROM issues;

  1. How many issues were created that we don’t have historical records for?

SELECT COUNT(DISTINCT key)
FROM (SELECT i.project, i.key, i.type, h.issue
FROM history h
RIGHT OUTER JOIN issues i ON i.key = h.issue)
WHERE issue IS NULL;

  1. What is the average Time to Close per project, since the moment tickets were first created? (assuming an issue is closed when its status gets Done)

WITH new AS (
SELECT i.project, h.issue, i.created AS created, h.created AS timepoints
FROM history h
INNER JOIN issues i ON i.key = h.issue
WHERE i.status in (‘Done’)),
range AS (SELECT project, issue, MIN(created) created, MAX(timepoints) timepoints FROM new GROUP BY project,issue),
diff AS (SELECT project, issue, DATEDIFF(day, range.created, range.timepoints) days FROM range)

SELECT project, ROUND(AVG(days),0) Days_to_complete
FROM diff
GROUP BY project;


But I’d rather keep investigating the datasets in R, due to its flexibility and data visualization capabilities.

library(readr)
library(dplyr)
library(tidyr)
library(ggplot2)
library(RColorBrewer)
library(treemapify)
issues <- read.csv("~/Desktop/READYissues.csv")
history <- read.csv("~/Desktop/history.csv")
issues$Created <- as.POSIXct(issues$Created, format = "%Y-%m-%d %H:%M", tz="GMT")
history$Created <- as.POSIXct(history$Created, format = "%Y-%m-%d %H:%M", tz="GMT")

In total, there are 4247 issues created between 2016-03-23 14:36:00 and 2018-07-06 11:03:00, which are distributed across projects and types the following way:

Total Number of Issues
Type CVAL DFO DW GTM TAL
Bug 194 338 397 120 189
Bug - Sub-Task 84 12 35 50 0
Epic 17 12 34 12 25
Idea 7 0 1 0 29
Initiative 1 1 1 2 4
Question 7 4 11 3 3
Research 4 2 2 12 13
Story 280 235 511 240 306
Sub-task 133 78 145 119 295
Task 64 20 69 84 40
Technical Sub-Task 2 0 0 0 0

DW and TAL are the projects which created the largest amount of issues. Bugs and Stories are the most popular types. Types of issues seem to follow a similar trend across different projects, as suggested in the table above (also represented in the chart below):

Despite the similar distribution of types of issues across projects, is important to highlight the fact that DFO is the one with the largest share of bugs.

But how have issues evolved overtime?

In July 2018 the volume of tickets created plunged because we only have records until 2018-07-06 11:03:00. Would be great to break down this growth in order to better understand its roots.

From May 2017, the volume of tickets increased due to DW. In October 2017, GTM massively contributed to tickets volume and, from November 2017, it increases further due to both CVAL and DFO. But it is because of these two projects that we see a sudden drop in April 2018. Also, TAL gets particularly representative in January and May 2018.

In terms of types of tickets, evolution goes the following way.

Bugs and Stories are the most popular types of tickets, but Sub-Tasks have consistently gained ground recently. Further details in attachments.

And how are tickets creation spread in a month? And in a week? What about in a day?

I believe there’s nothing wrong with the time tickets are created, they follow a fair distribution in a month, week or day.

If we take a closer look at the history and issues files, we realize we lack historical data for 542 tickets. See further analysis in attachments.
But let’s focus our investigation on tickets which have historical data. So, let’s merge both datasets in order to go deeper in tickets’ dynamics.

From all 4247 issues created, we only have historical data for 3705 and only 2341 issues were completed/done. Each ticket follows a specific path to get done, going through different stages and authors, taking different timings. We can get a summary of these metrics by ticket the following way:

hi_resume <- hi %>% 
  group_by(Project,Issue,Type,Status) %>% 
  summarise(requested = min(`First Created`), kickoff = min(Created), delivered = max(Created), status_changes=n(), nr_authors = n_distinct(Author)) %>%
  mutate(time2kick = as.numeric(round(difftime(kickoff,requested,units="days"),0)), leadtime = as.numeric(round(difftime(delivered,kickoff,units="days"),0)), totaltime = as.numeric(round(difftime(delivered,requested,units="days"),0))) %>% as.data.frame
head(hi_resume)
##   Project    Issue     Type Status           requested             kickoff
## 1    CVAL  CVAL-10    Story   Done 2017-09-22 15:14:00 2017-09-25 16:22:00
## 2    CVAL CVAL-101      Bug   Done 2017-11-15 18:33:00 2017-12-07 12:04:00
## 3    CVAL CVAL-102      Bug   Done 2017-11-15 18:39:00 2018-01-10 11:09:00
## 4    CVAL CVAL-104    Story   Done 2017-09-04 13:45:00 2017-10-18 14:42:00
## 5    CVAL CVAL-105 Sub-task   Done 2017-02-02 14:54:00 2017-11-06 16:22:00
## 6    CVAL CVAL-106 Sub-task   Done 2017-09-04 13:39:00 2017-11-06 16:23:00
##             delivered status_changes nr_authors time2kick leadtime
## 1 2017-12-13 17:17:00              2          2         3       79
## 2 2018-01-25 16:26:00              5          2        22       49
## 3 2018-01-25 16:22:00             11          3        56       15
## 4 2017-12-19 11:28:00              6          2        44       62
## 5 2017-11-13 19:39:00              4          1       277        7
## 6 2017-11-13 19:39:00              4          1        63        7
##   totaltime
## 1        82
## 2        71
## 3        71
## 4       106
## 5       284
## 6        70

In my perspective, time can be divided into 3 distinct stages:
1. Requested when the issue was first created in the platform;
2. Kick Off when the first stage of the process was completed and the ticket moved to the next one;
3. Delivered when it reached the last stage in our records, either completed or not.

Therefore, we can come up with 3 metrics:
1. Time2kick tells us two things at once: how long the issue waited in the line until it was first picked up by the first stage, plus how long the first stage took to complete;
2. Lead time which represents the time it took from the second stage until it reached the last stage in our records;
3. Total time which is the sum of the previous two stages, or the time it took since it was created in the platform until it reached the last stage in our records.

We can also get the number of status changes each ticket went through, as well as the number of distinct people who owned them (nr_authors).

From here, we can develop a lot of different views for our data. I am curious about how these new variables correlate with each other… Of course total time is highly correlated with both lead time and time2kick. Also, status changes with nr_authors is expectable, as the more stages issues go through, the more distinct people are likely to be involved. However, I was surprised to see that status_changes and nr_authors don’t correlate at all with any of the time variables. Furthermore, I was also expecting to see some kind of correlation between time2kick and leadtime, as per haps the more time consuming issues are, the quicker they would be picked up. But our data doesn’t confirm this relationship.

How are these variables distributed? For example, how does time behave?

Overall, 50% of issues take around three weeks to reach to their last stage (either completed or not). What happens to time variables across Projects? (there are plenty of outliers in our dataset and the maximum value for total time is 739 days, but I will establish shorter y limits for the sake off better viz).

It looks like time doesn’t vary that much across Projects. Below there’s a summary table for each one of the variables above, by project. I used medians as a measure to compare projects, so we can avoid the outliers effect.

Project status_changes nr_authors time2kick leadtime totaltime
CVAL 6 2 5 8 21
DFO 4 2 2 3 15
DW 3 2 3 8 28
GTM 4 2 1 5 15
TAL 6 2 5 8 21

DFO and GTM are the projects where issues are taken care more quickly. It is impressive how time2kick weights so much over totaltime for CVAL and TAL. It means that either these projects take so long to pick issues up, or their first stage is very time consuming.
One hypothesis is that it might depend on the types of issues they usually deal with. We will further investigate their relationship in a while, but before that, I want to execute the same view for types of issues only.

Type status_changes nr_authors time2kick leadtime totaltime
Bug 2.0 1.0 5.0 0 19.0
Bug - Sub-Task 7.0 2.0 0.0 6 8.0
Epic 1.0 1.0 121.0 0 181.0
Idea 1.0 1.0 100.5 0 123.0
Initiative 2.0 2.0 220.5 44 318.0
Question 1.0 1.0 1.0 0 2.0
Research 1.0 1.0 20.0 0 20.0
Story 5.0 2.0 4.0 15 30.0
Sub-task 7.0 2.0 1.0 6 11.5
Task 3.0 1.0 16.0 1 36.0
Technical Sub-Task 12.5 2.5 9.0 9 18.0

Epic, Idea and Initiative issues show a lot of variability and much higher total time, when compared to other types such as Bugs or even Questions. A plausible reason for this situation is the fact that these types of tickets are more complex and time consuming to implement, than fixing bugs, for example.

But how do types of issues relate with projects?

Here we can see one of the reasons why DFO and GTM see their issues being solved quicker than remaing projects: the types of issues which take a long time are not created under DFO and GTM.
Bugs, stories and sub-tasks take approximately the same time to be solved across projects. Research in CVAL and Epics in TAL take forever…

Meanwhile, another question comes up: what about the difference between tickets which were solved by the time of this extraction and the ones which are still pending?
Firstly, a quick look at volumes… (further details here)

More than half of DFOs’ stories haven’t been solved yet. Sub-tasks (including Bugs and Technical) are extraordinarily successful in their completion.

I think would be valuable to perform a similar analysis for our metrics, taking into consideration the issues which were solved and the ones still to be completed.

This tells us that the quicker issues are picked up, their chance of being solved is higher than the ones which remain in standby for a long time. Time to kick off highly affects issues’ delivery. In fact, lead time doesn’t seem to be excessively high.
Issues for CVAL and TAL projects take too long to be picked up. They deal with Epics and Ideas more than their counterparts, but that shouldn’t be the only reason, as volumes of these types are low. The trend also happens for Stories, for example, where these projects take some time to start off:
Project time2kick
CVAL 6
DFO 2
DW 3
GTM 1
TAL 9
Note:
Data for Stories only.

CVAL and TAL take a median of 6 to 9 days to kick off Stories, respectively.

What about the distribution of time to kick off by type? How does it look like?

Again, to confirm my previous statement, the longer issues take to kick off, the less chances they have to get completed. Initiatives, for example, never got done! Conversely, Technical Sub-Tasks were all completed.

Therefore, I believe that the kick off moment is extraordinarily important in predicting whether issues will be solved and how fast this will happen. So, it is key to deep dive into the first stage of the process.

Typically, the first stages of the process are To Do and Screen Issue. There are a few issues which start off with different stages, but for the purpose of our analysis, we can ignore these exceptions and focus on these two. In fact, 99.76% of total issues start either on To Do or Screen Issue.

More than half of issues which start at Screen Issue don’t get done. Overall, how long does this step usually take?

From.String time
Screen Issue 35 days
To Do 2 days

When an issue starts with To Do, it usually takes 2 days to pass onto the next stage, whereas when it starts with a Screen it takes around 35 days. The difference gets even larger if we consider the issues which are successfully completed.

Solved?
From.String No Yes
Screen Issue 63.5 days 15 days
To Do 3.0 days 2 days

The Projects which are most affected by this delay are DW, CVAL and TAL.

The Types of issues which are most affected by screen issue’s delay are Bugs and Stories. Further details here


Final Thoughts

  • The dynamics analyzed above suggest there is a hierarchical order for types of issues;
  • The first stage in the process is a key moment - it highly affects total time of tickets’ completion. The quicker they are picked up, the higher the chances they will be solved whithin a reasonable timeframe;
  • The Screen Issue stage is the bottleneck. It is the stage where tickets take the longest time to progress, when compared to remaining first stages. I would recommend assigning more collaborators to this step;
  • Epics, Ideas and Initiatives take much longer to develop than remaining types of issues, as they depend on the completion of certain types of issues to proceed.

Attachments

Evolution of Tickets creation by Type and Project

Back

Missing Historical Data

Below, we see the number of tickets by type and project where historical data is missing: Historical data is missing across all projects and types of issues, except for Bug-Sub-Tasks and Technical Sub-Tasks. However, status are not distributed the same way… Interestingly, from all 2341 issues completed, we don’t have historical data for only 1 of them:

subset(issues[issues$Status=="Done",], !(Issue %in% hi[hi$Status=="Done",]$Issue))
##      Project  Issue       First Created Status Type   month day
## 4247    CVAL CVAL-1 2017-10-04 20:07:00   Done  Bug 2017-10  04
##      day_of_week hour
## 4247   Wednesday   21

Back

Issues solved, by Project and Type

Number of Solved Issues
CVAL DFO DW GTM TAL
Bug 89 120 213 39 104
Bug - Sub-Task 84 8 31 46 0
Epic 1 0 11 0 0
Idea 0 0 0 0 10
Initiative 0 0 0 0 0
Question 2 2 4 2 2
Research 0 0 1 5 11
Story 161 43 229 152 183
Sub-task 91 53 118 105 273
Task 27 7 36 43 32
Technical Sub-Task 2 0 0 0 0
Share of Solved Issues
Type CVAL DFO DW GTM TAL
Bug 0.53 0.51 0.58 0.34 0.58
Bug - Sub-Task 1.00 0.67 0.89 0.92 0.00
Epic 1.00 0.00 0.44 0.00 0.00
Idea 0.00 0.00 0.00 0.00 0.42
Initiative 0.00 0.00 0.00 0.00 0.00
Question 0.67 1.00 0.44 0.67 0.67
Research 0.00 0.00 0.50 0.45 0.85
Story 0.68 0.24 0.49 0.68 0.68
Sub-task 0.88 0.68 0.89 0.89 0.94
Task 0.57 0.50 0.60 0.56 0.80
Technical Sub-Task 1.00 0.00 0.00 0.00 0.00
Median of Time2Kick for Solved Issues
Type CVAL DFO DW GTM TAL
Bug 5 3 6.0 4 5.5
Bug - Sub-Task 1 0 1.0 0 0.0
Epic 0 0 71.0 0 0.0
Idea 0 0 0.0 0 11.0
Question 1 105 0.5 3 7.5
Research 0 0 0.0 0 20.0
Story 5 11 1.0 0 9.0
Sub-task 4 0 0.0 1 1.0
Task 9 21 18.5 6 5.5
Technical Sub-Task 9 0 0.0 0 0.0
Median of Lead Time for Solved Issues
Type CVAL DFO DW GTM TAL
Bug 17 5.5 2.0 0 6.0
Bug - Sub-Task 6 0.5 12.0 5 0.0
Epic 2 0.0 146.0 0 0.0
Idea 0 0.0 0.0 0 14.5
Question 0 0.0 0.0 0 0.0
Research 0 0.0 8.0 14 0.0
Story 20 12.0 26.0 16 20.0
Sub-task 6 4.0 8.0 7 6.0
Task 8 0.0 9.5 0 15.0
Technical Sub-Task 9 0.0 0.0 0 0.0

Back

Issues solved vs not solved when Screen Issue as first stage

% of Solved Issues by Project & Type
CVAL DFO DW GTM TAL
Bug 0.36 0.11 0.69 0.40 0.30
Bug - Sub-Task 1.00 0.00 1.00 0.00 0.00
Epic 0.00 0.00 0.48 0.00 0.00
Idea 0.00 0.00 0.00 0.00 0.07
Initiative 0.00 0.00 0.00 0.00 0.00
Question 0.00 0.00 0.00 0.00 0.00
Research 0.00 0.00 0.50 0.00 0.00
Story 0.15 0.12 0.50 0.23 0.33
Sub-task 0.57 0.00 0.82 1.00 0.00
Task 0.09 0.00 0.58 0.00 0.60
Technical Sub-Task 0.00 0.00 0.00 0.00 0.00

Back